Finding: [BLOCKING] Fix ResourceRequest before publishing the client types

• Location: src/extensions/documentation/documentation/1.0.0/full_documentation.json:29477, propagated to src/gen/types.ts:11369.
• The runtime Resource schema requires title, description, slug, campaign, and publishDateVisible.
• ResourceRequest instead resembles ArticleRequest: it requires featured, includes categories, authorsBio, and tags, omits campaign, and marks title and slug optional.
• Both POST /resources and PUT /resources/{id} reference this request schema. Consumers therefore cannot express a valid typed Resource mutation without casts and are guided toward fields the runtime model does not accept.
• The response schema also marks required title and slug as optional.

Suggested fix

• Correct the OpenAPI generation/source so Resource request and response schemas match the committed content type. If updates are partial, consider separate create and update request schemas.
• Regenerate src/gen/types.ts and add a contract check covering campaign, required fields, and the absence of Article-only fields.

Finding: [BLOCKING] Align the fields query type with the cow.fi consumer

• Location: src/api/resource/documentation/1.0.0/resource.json:131, propagated to src/gen/types.ts:17775.
• The new GET /resources operation declares fields?: string, while the companion cow.fi implementation passes fields: ['slug', 'campaign'].
• That PR explicitly waits for this package's typed /resources endpoints. With the contract currently generated here, the two PRs still will not typecheck together after the package bump.

Suggested fix

• If the intended wire shape is the array used by the query serializer, define fields as an array of strings in the Resource OpenAPI parameter and regenerate the full documentation and client types.
• Otherwise, update cow.fi to use a documented, runtime-verified string encoding. In either case, add a small compile-time/integration check for the exact getAllResourceSlugs query.

Finding: [QUESTION] Align the Resource block choices with what cow.fi can render

• Location: src/api/resource/content-types/resource/schema.json:40.
• CMS authors can select shared.media, shared.quote, shared.rich-text, shared.slider, and shared.video-embed.
• The companion renderer only renders blocks containing a string body. Media, slider, and video blocks disappear; quotes are rendered as plain rich text, dropping their title/author semantics.
• Is v1 intentionally rich-text-only, or should cow.fi support every block exposed to Resource authors?

Suggested fix

• For a rich-text-only v1, restrict the Resource dynamic zone accordingly. Otherwise, add matching cow.fi renderers before exposing the other block choices, plus one fixture/test per supported block type.

Verify these findings against the current heads of cowprotocol/cms#94 and
cowprotocol/cowswap#7846, and fix only those still valid.

1. Make ResourceRequest and Resource response requiredness match the Resource
   content type, including campaign and excluding Article-only fields.
2. Make the GET /resources fields parameter and cow.fi's
   fields: ['slug', 'campaign'] query agree without casts, using a wire format
   verified against Strapi and the configured query serializer.
3. Decide whether Resource v1 is rich-text-only. Either restrict the CMS block
   choices or render every allowed block faithfully in cow.fi.

Regenerate the full OpenAPI document and src/gen/types.ts, then add focused
contract/type checks for the mutation schema, slug query, and supported blocks.

Generated using the pr-review skill from the CoW Protocol skills repo.